Kapitel 26 Datenbankzugriff mit ADO.NET
Bei den meisten Anwendungen spielen Daten eine eminent wichtige Rolle. Häufig werden diese Daten in einer Datenbank gespeichert. Vor der Einführung von ADO.NET hat Microsoft verschiedene Datenzugriffstechnologien für den Zugriff und das Speichern von Daten eingesetzt. Der direkte Vorgänger von ADO.NET war Microsoft ActiveX Data Objects (ADO), eine verbindungsorientierte Datenzugriffstechnologie, der allerdings Schlüsselfunktionen fehlen, um auch sehr große, verteilte Anwendungen zu erstellen.
26.1 Eine kleine Einführung
ADO.NET integriert sich mit seinen Klassen in mehreren Namespaces des .NET-Frameworks. Von der Idee her soll ADO.NET den Entwicklern dabei helfen, effiziente mehrschichtige Datenbankanwendungen über Intranets und das Internet hinweg zu erstellen. Daraus resultiert eine zweischichtige Klassenarchitektur: Es gibt Klassen, deren Objekte mit der Datenbank verbunden sind, und Klassen, deren Objekte als unverbundene Objekte bezeichnet werden. Zu den verbundenen Objekten zählen unter anderem die Klassen Connection, Command und DataAdapter, zu den unverbundenen die Klasse DataSet und DataTable. Auf alle werden wir noch eingehen.
Sie können nicht erwarten, dass in diesem Kapitel sämtliche Aspekte von ADO.NET erläutert werden. Dafür ist das Modell mit allen seinen Möglichkeiten einfach zu komplex und würde für sich alleine ein ganzes Buch füllen. Ich werde aber versuchen, Ihnen die meiner Ansicht nach wichtigsten Klassen vorzustellen, Ihnen zu zeigen, wie Sie Daten abrufen und eine Datenbank aktualisieren können. Es werden zwar noch viele Fragen bleiben, aber mit diesem Kapitel sollten Sie zumindest ein gutes Fundament haben, um problemlos eigene Datenbankanwendungen zu programmieren. Weil dieses Buch sich fast ausschließlich nur mit Desktop-Anwendungen beschäftigt, bleiben die Aspekte mehrschichtiger Anwendungen außen vor.
| Hinweis Der Programmcode in den folgenden Beispielen setzt voraus, dass Sie SQL Server 2000 bzw. die neue Version SQL Server 2005 (z.B. die Express Edition) installiert haben. Alle folgenden Beispiele gehen davon aus, dass Sie darüber hinaus die Beispieldatenbank pubs installiert haben. Da diese Beispieldatenbank standardmäßig nicht zum Lieferumfang von SQL Server 2005 gehört, können Sie die Installationsroutine entweder über
http://msdn2.microsoft.com/de-de/library/ms143221(SQL.90).aspx
downloaden oder die Installation direkt von der Buch-CD starten.
|
Bevor auf die Dateninformationen in einer Datenbank zugegriffen werden kann, muss eine Verbindung zu der Datenquelle hergestellt werden. ADO.NET stellt dazu passende Klassen zur Verfügung, mit denen eine Verbindung aufgebaut und gesteuert werden kann.
Die erste Frage, die es zu klären gilt, ist die nach dem Typ des Datenspeichers. Damit entscheidet sich auch, welcher Datenprovider zum Einsatz kommt. Das .NET Framework stellt mehrere zur Verfügung:
|
SqlClient-Provider |
|
|
OleDb-Provider |
|
|
Odbc-Provider |
Ein Datenprovider ist eine Ansammlung von Klassen, die den Zugriff auf einen bestimmten Datenspeichertyp ermöglichen. Jeder .NET-Datenprovider implementiert dabei die gleichen Basisklassen, beispielsweise Connection, Command und DataAdapter. Der tatsächliche Name hängt vom gewählten Provider ab. So bietet der SqlClient-Provider beispielsweise die Klasse SqlConnection an, der OleDb-Datenprovider die Klasse OleDbConnection. Unabhängig davon, für welchen Datenprovider Sie sich entscheiden, die Schnittstellen und damit die Funktionalitäten bleiben gleich. Nahezu unabhängig von der Providerwahl ist auch der Programmcode. Sollten Sie vielleicht gezwungenermaßen zu einem späteren Zeitpunkt den Provider wechseln, brauchen Sie möglicherweise den Programmcode überhaupt nicht zu überarbeiten.
Häufig sind Sie nicht auf einen einzigen Datenprovider festgelegt, sondern können für den Zugriff auf eine Datenquelle zwischen mehreren auswählen. Ist die Datenquelle ein Microsoft SQL Server in der Version 7.0 oder höher, empfiehlt sich der SqlClient-Datenprovider, weil dieser für die genannten Versionen des SQL Servers optimiert ist.
Jeder .NET-Datenprovider hat einen eigenen Namespace, der ein Unternamespace von System.Data ist und bekannt gegeben werden sollte. Ist die Quelldatenbank der SQL Server, handelt es sich um System.Data.SqlClient. In den Beispielen dieses Kapitels werde ich ausschließlich den SqlClient-Datenprovider benutzen. |
